This improves textkit line slicing performance for long paragraphs without changing line-breaking behavior.

Changes:

• use binary search in glyphIndexAt instead of scanning backward through the full glyph index array
• count ligature offsets by scanning the local repeated-index cluster instead of slicing/filtering the whole prefix
• build breakLines with push instead of copying the accumulated line array on every breakpoint

Measured in a downstream PDF generator with a single long left-aligned body paragraph:

Baseline, 200k chars: ~31.3s wall, ~43.5s CPU, ~3.38GB maxRSS
With these textkit changes: ~17.0s wall, ~26.4s CPU, ~3.33GB maxRSS

Together with #3421, this improves performance in the same downstream PDF generator by:

Baseline, 50k chars: ~2.4s wall, ~3.0s CPU, ~563MB maxRSS
With #3420 + #3421: ~713ms wall, ~1.11s CPU, ~291MB maxRSS

Baseline, 100k chars: ~8.1s wall, ~10.1s CPU, ~1.18GB maxRSS
With #3420 + #3421: ~1.21s wall, ~1.73s CPU, ~423MB maxRSS

Baseline, 200k chars: ~31.3s wall, ~43.5s CPU, ~3.38GB maxRSS
With #3420 + #3421: ~2.28s wall, ~2.96s CPU, ~513MB maxRSS

The memory profile is mostly unchanged with this PR alone because the dominant heap allocation comes from the Knuth-Plass active-node search, but the CPU/wall-time improvement is still measurable.